OPC UA (OPC Unified Architecture) is a standard industrial protocol of the OPC Foundation for manufacturer-independent communication for the exchange of machine data, particularly in process automation.
OPC UA is a relatively novel standard, in which the original focus was not on the control of an industrial facility, but rather on standardized information exchange, particularly between devices from different manufacturers.
In the meantime, OPC UA is also integrated directly in automation devices, so that the need for consistent writing of data arises.
In automation plants, there is the need to exchange process information (such as process values, measured values, parameters, control commands) between different devices. Here it is important that the information is transmitted between the users consistently and faultlessly. This is particularly important for data-modifying calls (i.e. the writing of variables).
In practice, consistency must be ensured over a plurality of individual calls in the plant. Thus, it may be the case that a modification in the process intervenes at a plurality of points in the process, the targets of the calls being different and having to be addressed by different calls.
Other reasons for the need for a plurality of different, but logically coherent calls would for example be:                different security settings,        different type of call (write, method call),        organizational reasons.        
In OPC UA, variables are considered individually (even within what is known as a WRITE call with a plurality of variables); the server shares these variables with the client by means of individual status codes (per variable). Other options are not provided in the specification.
The information model specified by the OPC UA is no longer only a hierarchy made up of folders, items and properties. It is what is known as a full mesh network made up of nodes, using which, in addition to the user data of a node, meta information and diagnostic information are also represented. A node is similar to an object from object-oriented programming. A node can have attributes, which can be read (Data Access DA, Historical Data Access HDA). It is possible to define and to call methods. A method has calling arguments and return values. The method is called by a command. Furthermore, events are supported, which can be sent (AE, DA DataChange), in order to exchange certain information between devices. An event has a time of receipt, a message and a severity level, inter alia. The abovementioned nodes are used both for user data and for all other types of meta data. The thus modeled OPC address space also now contains a type model, using which all data types are specified.
In OPC UA, a session concept (session) is known, which is implemented using special service calls (BeginSession, ActivateSession, EndSession). There may be a plurality of sessions which exist simultaneously on a server. However, within an OPC UA connection, there is always only one such session active at a time. Sessions are used inter alia to assign a user or a role uniquely.
Without violating the OPC UA standard, a client and a server (which are tailored to one another) could agree that the server regards a Write call as exactly one consistent write operation and only accepts this call as a whole or rejects this call as a whole.
However, this mechanism is not—as described above—valid in general, but rather functions only                if client and server are tailored to one another. Client and server must exchange the information that they are tailored to one another, i.e. this information must be transmitted e.g. in the logon protocol,        if there is exactly one modifying call and/or        if the targets of the write operations are located on the same target system (aggregating servers could not be handled hereby).        
As already stated above, this is not sufficient in practice, as consistent operations often cannot be covered using a single modifying call.
It is therefore the object of the invention to specify a method and an apparatus which overcomes the above-described problems.
The described object is achieved by means of a method and an apparatus according to one of the independent patent claims.
A method is claimed for communication between an OPC UA client and an OPC UA server of a client/server system using the OPC UA communication protocol, OPC UA calls being used for the interaction of the client with the server, wherein the communication is executed in a session-based manner and after opening a session, at least one OPC UA call is received and stored by the server and the execution of the OPC UA call is initially simulated at the server and the result of the simulation is initially transmitted to the client as response.
According to the invention, an OPC UA session is regarded as a single transaction. A transaction begins with the service call for CreateSession or ActivateSession. A transaction is ended (with execution) by the service call CloseSession or ActivateSession. A transaction is canceled (i.e. without execution) with the service call Cancel.
That means: the command ActivateSession ends a previous transaction (with execution) and begins a new transaction.
Transaction in this context means that all service calls up to the abovementioned one are only simulated and not executed and the execution of the service calls is deferred to the ending of the transaction.
Each operation within a session is formally checked and subsequently simulated. The simulated result or the result of the formal check is sent to the client immediately. The client therefore receives a preview of the result of the operations.
If the client determines that one of the operations carried out would not lead to the desired result, they can discard the operations. If the client wants the set operation to be executed, then the client ends the current session. Should a further set operation be created, the client ends the session. The set operation is executed and the session is set to the original state. If no further set operation should be created, the client ends the session. Server and client agree when the connection is established about the activation of the suggested mechanism.
As stated above, the problem of the consistent data-modifying set operation is not currently addressed by OPC UA. This will increasingly be an important requirement in the future, particularly in communication between automation systems.
This invention solves precisely this problem.
In a surprising manner, the sessions defined by OPC UA are expanded by the capability to carry out transaction-oriented set operations. This is achieved in that the execution of the operations within a session is deferred to the end of the session. All calls which are carried out within such a session receive the normal service results thereof. These are merely afflicted with the uncertainty that they are only simulated. Nothing has to be changed in the fundamental mechanism of the calls within a session.
By contrast with the already known transactions, this method does not have the option of a rollback, that is to say a reversal of the operation execution. Upon closer consideration, one determines that this is often neither necessary nor implementable or sensible for automation technology. When a valve is first opened, the state prior to the opening of the valve can no longer be produced, because e.g. liquid has already escaped from a container. That is to say, in addition to the closing of the valve, that is to say the production of the initial state “from the perspective of the valve” another step (cleanup) must also be carried out. Therefore, a rollback known from the database environment is not possible in this example.